Currently, automatic repeat request (ARQ) is one of the fundamental techniques in improving the reliability of data transmission in communications networks where transmission errors are possible. Several ARQ protocols exist, but a common characteristic for all of them is the basic idea that a Receiver requests a retransmission of the data packets that the Receiver has not received. There are several ways in which a Receiver may determine that a packet was not received.
For instance, the Receiver may determine that a packet was not received in an instance in which the packet does not arrive when it was expected to arrive. Additionally, the Receiver may determine that a packet was not received in an instance in which the packet is marked with a sequence number and a packet with a greater than expected sequence number is received. As another example, the Receiver may determine that a packet was not received in an instance in which the received packet is broken. The received packet may be broken in an instance in which there are bit errors in the packet.
There are also various mechanisms in which a Transmitter may determine that a Receiver has not received a transmitted packet. For instance, the Transmitter may determine that a Receiver has not received a transmitted packet(s) in an instance in which a Receiver reports or acknowledges the received packets with a status report and one of the transmitted packets is not acknowledged as received. The Transmitter may also determine that a Receiver has not received a transmitted packet in an instance in which a Receiver does not send an acknowledgement in time.
The Receiver typically sends a status report either regularly or according to other criteria to a Transmitter. The status report is typically a list of missing data packets (e.g., using some form of packet identifier, usually the sequence number) and the identifier of the most recent correctly received packet. The status report may be sent to a Transmitter regularly at fixed or other time intervals. Additionally, the status report may be sent regularly after receiving a certain number of packets. As another example, the status report may be sent to a Transmitter regularly after receiving a certain amount of data or after detecting that a packet has been lost. The status report may also be sent by a Receiver to a Transmitter when the Transmitter requests a status report explicitly. This is typically implemented by setting a “polling flag” in the header of the transmitted data packet.
There are often several layers of ARQ protocols on top of each other. For instance, in Universal Mobile Telecommunications System (UMTS) and Long Term Evolution (LTE), the physical layer uses Hybrid Automatic Repeat Request (HARM) with incremental redundancy to achieve a certain reliability of packet transmission. The residual errors are managed with another ARQ protocol in the Radio Link Control (RLC), which is a sublayer of Layer 2. Although the RLC typically guarantees practically an error-free transmission, the Transmission Control Protocol (TCP) and Internet Protocol (IP) (TCP/IP) stack has also its own ARQ mechanism.
The radio channel has a number of challenging properties and one of the problems is the fact that the size of the transport blocks may be variable and the size of each data packet handled by the ARQ protocol may be variable. There are several reasons for this. For instance, the fading of the radio channel is addressed in LTE so that the physical layer adjusts the transmission rate according to the fluctuations in the channel capacity and allocates transport blocks of variable size to the upper layer accordingly. Additionally, the radio resources are shared by several User Equipment (UE) devices, so the amount of available resources depends on the congestion.
Several logical channels are multiplexed on a single transport channel, so the share each logical channel gets of a transport block may be different each time. In LTE, for instance, each logical channel has its own ARQ process, so this alone may cause variation in the available packet size from the ARQ point of view.
The amount of variation in the transport block size may depend on the cell type (e.g., macro, micro, pico, or femto cell), the number of UEs in one cell, and the motion of a UE. The variation typically gets smaller in an instance in which the cell size gets smaller.
The variable packet size may be a problem for the ARQ retransmissions, because a packet may not be easily retransmitted if the available transport block is smaller than the packet to be retransmitted. Several mechanisms exist to address the problem but these existing mechanisms still have drawbacks, as described more fully below.
For instance, the RLC layer of the UMTS attempts to minimize the problem by using a very small RLC Protocol Data Unit (PDU) size. This is accomplished by segmenting the RLC PDUs in small pieces such that each of the pieces separately may fit in any transport block, even the smallest possible transport blocks. This naturally means that a large amount of RLC PDUs are concatenated in the Medium Access Control (MAC) layer when the transport block is filled.
Currently, there are several problems with the UMTS approach. For instance, the segmentation of the RLC PDUs to small RLC PDUs may be a heavy task and as such the processing load may undesirably increase with the high data rates. There is also a certain amount of padding at the end of the transport block. If the processing load problem is alleviated by increasing the RLC PDU size, the average padding gets larger. However, minimizing the padding by making the RLC PDU smaller may exacerbate the processing load problem by increasing the processing load. Also, the range of the RLC PDU sequence numbers may need to be relatively large to maintain unambiguity.
The RLC of the LTE attempts to solve some of the problems with the UMTS approach so that the RLC PDU sizes are matched to the transport block sizes; for example, the physical layer identifies for each transmission the size of the transport block. Furthermore, the MAC layer typically allocates a certain portion of the transport block for each logical channel according to their priorities and amounts of data waiting to be transmitted. Each logical channel has its own RLC entity which takes care of filling the RLC PDU with the data of the corresponding logical channel. The RLC also takes care of the retransmissions according to the ARQ procedure. The problem of retransmitting a RLC PDU that is larger than the allocated piece of the transport block is solved so that the RLC PDU is re-segmented into smaller blocks. The segmented parts are generally identified by having the size and the byte offset of each segment expressed in the re-segmentation header of the re-segmentation extension of the RLC PDU format. The size of each re-segmented piece may be determined in the same way as the size of the original RLC PDUs. For example, the size of each re-segmented piece may be determined based on the largest possible size that fits into the allocated piece of the transport block.
Although the LTE solution is better than the UMTS solution, the LTE solution still has some problems and drawbacks. For instance, re-segmenting a RLC PDU may be tedious and the RLC PDU header structure may be complicated with the re-segmentation extensions. Moreover, the handling of sequence numbers of the re-segmented parts may be complicated and make the RLC specification rather complex and unclear.
In view of the foregoing problems and drawbacks, it may be desirable to provide an efficient and reliable mechanism to improve the efficiency of ARQ procedures in a communications system.